Choosing Names
「良い名前を付ける」
良い名前はドキュメントの一部となり、コードの理解を助ける
他のドキュメントの必要性を減らし、エラーを発見しやすくする
逆に悪い名前は、コードの複雑さを増大させ、バグの原因となる 曖昧さ や 誤解 を生みやすい 開発者の多くは、名前を付けることにあまり時間を割かない
思いついた名前をそのまま使ってしまいがち
より正確（曖昧でない・直感的）で、一貫性のある名前を選ぶのに時間をかけるべきである
すぐに元は取れるし、繰り返すことで良い名前を選べるようになる
名前を付ける際の目標は、読み手の頭の中に「名付けられたものの本質に関するイメージ」を作り出すこと
良い名前は、「根底にあるものが何であるか。逆に、何でないか」に関する多くの情報を伝えるものである
名前を付ける際には、「もし誰かが、宣言やコメント、使用箇所のコードを見ないでその名前だけを見たときに、その名前が何を指しているかどれぐらい推測できるか？」を自問自答するのが良い
また、単一の単語では限界があるので、最も重要な側面を捉える数語を見つけ出せるかが鍵である
∵ 名前 = 根底にあるより複雑な実体を隠蔽しつつ、シンプルに表現したもの
読み手がその名前が何を指しているのか分からない
数が多いので別ページに切り出したradish-miyazaki.icon
例外はある
正確な名前を思いつかない場合、その変数に明確な定義や目的が無いことを示唆している
e.g. 1つの変数で複数のことを表現している
この場合、変数やメソッドの宣言自体を見直す必要がある
その名前をあるコンテキストで見たら、異なるコンテキストで見たときに推測しやすい
e.g. 一番外側のループ反復子には i、ネストした場合は j を使う
e.g. Go の context.Context インスタンスを ctx にする radish-miyazaki.icon
一貫性のある名前とは、具体的に以下のような名前を指す
ある同一の目的のために使う場合、共通の名前を使う
その目的以外では使わない
その名前を持つ変数が同じように使われるために目的は十分に絞ること
同じものを参照する複数の変数が必要になるケースもある
e.g. ファイルデータをコピーするメソッド
コピー元とコピー先の2つの変数が必要
e.g. srcFileBlock / dstFileBlock
Go は「名前は非常に短くすべき」という考えが根付いている long names obscure what the code does.（長い名前はコードが何をするのか 不明瞭 にする） その一方で、以下のようにも述べている
The greater the distance between a name’s declaration and its uses, the longer the name should be.
（名前の宣言とそれを使用している箇所との距離が遠いほど、名前はより長く付けるべきである）
この短い名前は 一貫性 を持たせれば、認知的負荷を軽減できる radish-miyazaki.icon 一方、短くすると必然的に曖昧になるので、正確性 は無い Go のケースを踏まえると、最終的に可読性は書き手ではなく、読み手が決める必要がある 短い変数名を付けても、読み手がそれを理解しやすいと感じればそれで良い